M. Brandon Miller dot com

Rather than wasting any time, I'll just jump straight into the next round of rapid prototyping.  Also, pirates.

This time the focus was on telling a complete story with the game.  This game was a particularly wacky take on high seas survival horror.  The wackiness peaked when the team decided to include an enraged and undead sea cow as a pivotal plot point, and then hide this fact until the moment the game was presented.

On the technical side, I took what I had learned about platforming and punching and expanded it to a quasi-3D environment similar to classic beat-em-up arcade games.  

Of course, beating up zombies will only keep them down for so long, so to permanently dispatch them, there's a more gruesome approach in which our hero puts his hook hand to work.  The zombie is actually removed immediately during this move, and the hero and zombie then appear in a canned 'finishing move' animation.

The trade-off between the two was intended to be the time that must be spent in that animation, as the game becomes a race against the clock starting with the second stage.

In addition to the pirate-on-zombie violence, the game also featured a looting and pillaging system in the form of a lock-picking mechanic, which I pretty much stole entirely from Oblivion.

However, the twist here is that lockpicking must be done in real time while on the run from zombies.

Here is some of the Actionscript that displayed the lockpicking UI.  It could be overlaid at any time provided the hero was close enough to the object he was trying to unlock.

I included the first part of the ending here in part to credit the students who worked with me on this and in part because of the zany.

Today I wanted to look at another fun topic involving robots and explosions.

For the first round of Rapid Prototyping at FIEA, each team was given an existing intellectual property to work with, chosen at random from a list provided by the students.

I was lucky enough to be on the three-man team that received the topic of Transformers.  Our team of programmer, producer, and artist decided to base our game on the fight between Optimus Prime and Megatron from the begining of the 1980s animated move.

On the code side, I actually began using my individual game as a base.  I stripped the level down to one platform, added a second player, and bound the 'camera' to the mid-point between them.

As for the actual fighting action, I altered my run-and-gun shooting code to 'shoot' what I called 'punch zones'.

The 'punch zone' class and a sample of the 'punch zone' 'shooting' code can be seen here.

These zones were actually based on the hit-sparks from the previous game.  Visual flashes that would vanish within an instant.  They were altered to be invisible boxes that would appear in an instant to deliver a blow and then vanish.

This idea of having moves project hit-boxes was one I picked up by over-analyzing M.U.G.E.N. during my spare time in my undergrad years.  This is probably fairly standard practice in 2-D fighting games, but I don't think it would have been obvious to me in such a short time had I not spent so much time staring at fighting game debug information.

The two fighters 'shoot' these boxes at certain times during their various attack animations, and the boxes have a variety of properties, such as damage and hit-stun and knock-back.

The system for determining which attack to deal out wasn't terribly elegant, amounting to a series of if statements and arbitrary code numbers, but for a two-week rapid prototype, it allowed us to get in a surprisingly large number of fighting game features.

This is the commentary post for this code sample.

As mentioned in the Postmortem, the challenge of creating enemy AI was not tackled until fairly late in the project.  So when it came time to attack the problem, the task seemed rather daunting.

Simply navigating the city was a big enough challenge for the AI, but they also had to pose a threat to the player and their giant doom tank.

I sought out the advice of the FIEA faculty, and the idea for this sort of approached was raised.  I would return later to help improve my skills with vector math, and the solution would become vastly more efficient.

The purpose of this example function is to update a series of priority weights corresponding to the radial directions surrounding an AI Vehicle.  Provided are the direction of its' goal (usually a path node or the player vehicle) and the distance to that goal.

The radial directions around the vehicle are given a favorable weight based on how little they deviate from the direction to the goal, and then unfavorable weights are added in based on the positions of obstacles, other vehicles, and the player vehicle.  The algorithm then weights these factors to decide on the 'best' path to travel down.

The AI Tanks will simply turn in place until they face their ideal direction and then press onward towards it.  However, AI Cars perform a simple simulation of driving physics in which they cannot turn unless they are moving either forward or backwards.  As a result, a 'mBackup' flag is set when they are in imminent danger of crashing in to an obstacle.  Their tolerance for nearby threats also drops when backing up, which causes them to get a wider window of safety before they start moving forward again.

A feature I had actually forgotten about until I looked at this file was a somewhat humorous attempt to prevent vehicles from falling into a deadlocked state of constantly waiting for other cars to get out of their way.  Vehicles could actually become frustrated with waiting and begin driving recklessly, without heed for safety.  In particular, civilian vehicles will panic and begin to do this if the player's vehicle gets too close.  This actually causes one to ram into a Squad Car in this video.

The player vehicle is an interesting case as it can also be the AI Vehicle's goal.  Vehicles will drive towards the player until they get within firing range.  However, since ramming in to the player's vehicle is fatal to them, they also try to avoid it once within a certain radius.  It's also worth noting that the 'mSuicidal' variable does exactly what it says on the tin.  It is flagged for enemies who actually benefit from kamikaze tactics.


This function and this class as a whole was a major challenge, but it was also a great deal of fun.  It was very exciting when the cars finally began to avoid one another and successfully navigate the streets of our New Detroit.  However, making them provide a fun challenge the player would require many more hours of work . . .